This is the template workflow filename, which is intended to serve as a unique identifier, and thus must be a bit more
verbose.

This will make it easier for the maintainers to sync fixes and improvements in either direction between the upstream
"template" workflow and its installation in this repository.

This will make it easy for contributors to discover information about the purpose and usage of the files.

These are the naming conventions established in the standardized template workflow.

Grammatical error.

This conditional was intended to prevent the workflow from causing confusion and annoyance to contributors with no need
or interest in publishing a nightly build as it failed daily in their forks due to the necessary secrets not having been
defined.

Since the time this was added to the workflow, GitHub Actions has been changed so that, even after enabling workflows
globally, scheduled workflows are disabled in forks. The forker must manually enable each scheduled workflow. I think
that the sort of contributor who is savvy enough to enable workflows is also savvy enough to understand from the workflow
name that it does not apply to their fork and skip enabling it. Even if they did accidentally enable it, they will
remember doing so when the workflow fails later that day.

Even though they are not necessary, it is best practices to always quote paths. Since the paths in the workflow use the
project name, it might be that quoting is necessary for a specific project and this is intended to be a template that can
apply to any project with the minimum of modification.

The previous environment variable name referenced the project name, which would be confusing when used with other
projects.

This makes it easy to apply the release workflows to any project with the minimum of configuration effort.

The `actions/upload-artifact` action's default behavior is to only issue a warning if no files are found at the path.
In these usages of the action, the absence of the files which are intended to be uploaded to a workflow artifact
indicates that something has gone horribly wrong. For this reason, the workflow should be configured to fail immediately
if this occurs.

A situation might arise where it is desirable to immediately trigger the nightly workflow. For example:

- Testing after changes to the workflow
- Testing after changes to or affecting the secrets used by the workflow
- Testing after changes to the download server infrastructure
- Immediately pushing a project change via the nightly distribution channel

I have found that the manual workflow trigger events stay harmlessly out of my way until the time when they become very
convenient in situations like the ones I listed above.

Although I haven't found a need for the `repository_dispatch` event yet, I think its could be valuable in the event that
it was necessary to trigger the nightly on multiple projects, in which case being able to automate the trigger would be
convenient.

Excessively long commands can be difficult to read.
Breaking them into multiple lines avoids the yamllint warning and improves readability.

Previously, the configuration of the workflow was such that a Datadog report was only submitted when the
`publish-nightly` job failed. In the event one of the other jobs failed, the `publish-nightly` job never ran, and neither
did the failure handling step inside the job.

We already had a real life event where the Arduino CLI nightly was failing due to a notarization problem, which was not
reported due to the workflow configuration.

The use of goreleaser was abandoned long ago, but the comment was not updated accordingly.

The `publish-nightly` job only depends on the contents of the workflow artifact produced by the previous job. It doesn't
use the repository for anything and thus has no need to check it out into the runner.

The GitHub Actions workflow that does releases of the project uses the `arduino/create-changelog` action to generate a
raw draft changelog made up of the commit history since the previous tag. Previously, the regular expression used to
identify the previous tag only supported production release versions. The standard prerelease tag names resulted in a
changelog that contained the entire commit history.

… workflow

Unquoted variables in shell commands can result in very confusing bugs caused by unexpected interpretation of characters
in the variable contents by the shell, such as globbing and word splitting.

Rather than attempting to consider all possible conditions the command might run under to determine whether quoting is
absolutely necessary, it's best practices to simply quote everything except in the rare circumstances where this will
break the command.

The `actions/create-release` action is no longer maintained. We have switched to using the `ncipollo/release-action`
action in multiple tooling project workflows and have had no problems with it. It perfectly satisfies all the
requirements for this workflow, which the other did not.

…ld commands

The Go release system uses a `git log` command to determine the commit in order to populate the
output of the application's `version` command. The expected output of the command is solely the short hash. With the
previous command, that expectation was not realized under the following conditions:

- The `log.showSignature` Git configuration option is set to true.
- The commit being built was signed (as is always the case when a commit is made via the GitHub web interface).

In this case, the signing information is shown in addition to the hash, breaking the build system.

The backticks command substitution syntax is discouraged in favor of the modern `$()` syntax for the reasons described here:
http://mywiki.wooledge.org/BashFAQ/082

The modern syntax is already in use for other dynamic variables in the taskfile, so this change also provides consistency.

… tags

Release builds are identified using the Git tag. It might occur that multiple tags are made at the same commit (as is
common with prereleases). The previous command returned both tags, which broke the build system. The updated command
returns only a single tag.

According to the official styleg uide:

https://taskfile.dev/#/styleguide?id=use-the-correct-order-of-keywords

The order should be:

- version:
- includes:
- Configuration ones, like output:, expansions: or silent:
- vars:
- env:
- tasks:

From https://taskfile.dev/#/styleguide?id=dont-wrap-vars-in-spaces-when-templating

> Don't pad inside taskfile templates

When this update was done for Arduino CLI, some difficulties were encountered with the release build system, the
workarounds for which required some changes to the "DistTasks.yml" taskfile. The extensive comments added in that file
explain the situation.

The update from Go 1.14 to 1.16 broke the task that runs golint. The good news is that the new `go install` command
eliminates the need for the workaround of running the `go get golang.org/x/lint/golint` command from outside the project
path.

The bad news is the `go list` command used to get the path of the golint installation does not work in the "module-aware
mode" that is now the default. In the end, I gave up on making the task work as before. I think it's better to require
the user to install golint and put the installation in the system PATH, displaying a helpful message when this has not
been done.

The Arduino Lint build process defines some variables with values that are used in the `--version` output. These variable
names have been modified in the standardized "template" build system, and so must also be modified here.

The new paradigm from Go is to use `go get` exclusively for maintaining project module dependencies with the newly
introduced `go install` used for applications such as the tool installations.